MAS V3.4 Protocol Reference V1

Appendixes

Appendix A. Interoperating with the IBM 6611 Router

A number of configuration considerations must be addressed for IBM Nways Multiprotocol Access Services's DLSw implementation to interoperate with those of the IBM 6611 router.

The following sections provide an overview of these considerations, and indicate which features of IBM Nways Multiprotocol Access Services's DLSw implementation are not interoperable with those of the IBM 6611.

Note:

The considerations cited here are derived from testing performed with the IBM 6611's MPNP V1.2 software. The considerations may not apply to other MPNP software versions.

The considerations have been categorized in the following sections:

• "Bridge Configuration Considerations"
• "DLSw-Related Considerations"
• "IP-Related Configuration Considerations"
• "TCP-Related Considerations"
• "Miscellaneous Interoperability Considerations"

Bridge Configuration Considerations

The following are bridge configuration considerations:

• The LAN identification (Segment number) of the DLSw must match on both the IBM 2216 and IBM 6611 routers. If a mismatch persistently exists, enter the IBM Nways Multiprotocol Access Services Configurator (Talk 6) and select the DLSw protocol. The set srb command can then be used to set a Segment Number value that matches the IBM 6611 equivalent.
• The maximum MTU value that can be used for the Bridge Frame is 2100 bytes. This is the largest value currently supported by the IBM 6611. If MTU values less than 2100 are specified, it is important that the configured values match on both the IBM 2216 and IBM 6611 routers.

DLSw-Related Considerations

DLSw-related interoperability considerations are as follows:

• The IBM Nways Multiprotocol Access Services DLSw implementation does not support generation of SSP_IAMOKAY message (SSP Message Type X'x1D') while IBM 6611 DLSw implementation is supported. This SSP message is undocumented in RFC 1434, and is silently discarded by the IBM Nways Multiprotocol Access Services DLSw implementation upon receipt.
• The IBM 6611 DLSw implementation processes SSP_ENTER_BUSY/EXIT_BUSY messages received from the IBM Nways Multiprotocol Access Services DLSw implementation but will not generate similar flow control related SSP messages.
• The IBM Nways Multiprotocol Access Services DLSw implementation does support the user defined SSP_TEST_CIRCUIT_REQ message (SSP message type X'x7A') that is generated by an IBM 6611 DLSw router functioning as an APPN network node. Upon receipt of this message, the IBM Nways Multiprotocol Access Services DLSw implementation will return the user defined SSP_TEST_CIRCUIT_RSP message (SSP message type X'x7B'). This response is expected by the IBM 6611 DLSw router's APPN network node implementation.

IP-Related Configuration Considerations

The following are IP configuration considerations:

• The client/server and peer/peer DLSw group feature that enables IBM Nways Multiprotocol Access Services DLSw neighbors to dynamically find each other is not interoperable with the IBM 6611 DLSw implementation. As a result, the DLSw's add tcp neighbor configuration command must be used to define the static IP addresses of adjacent IBM 6611 DLSw peers.
• The preceding interoperability restriction on the IBM Nways Multiprotocol Access Services DLSw group feature has implications for the selection of RIP/OSPF:
  • To utilize DLSw groups on an 2216, you must also configure OSPF/MOSPF. But because these DLSw groups are not interoperable with the 6611, it is possible to configure the 2216 with only RIP enabled and no OSPF configuration.
  • Although OSPF and RIP can both be enabled on the IBM 2216 side, MOSPF (if selected through the OSPF configuration) is not supported by the IBM 6611.
• Within the IBM Nways Multiprotocol Access Services IP configuration, make sure that the fill patterns configured for broadcast addresses on a given interface match their equivalent definitions on the IBM 6611.
• IBM Nways Multiprotocol Access Services's Bandwidth Reservation System (BRS), which can be utilized to guarantee bandwidth for the transport of SNA traffic over DLSw, is not interoperable with the IBM 6611 DLSw implementation.

  Although the priority assigned by the IBM 2216 hardware for BRS can be implemented in an outbound direction, the priority order will not be guaranteed if intermediate IP routers do not support BRS. Also, because the 6611 does not support BRS on its end of the line, BRS can only be applicable in a single direction.

TCP-Related Considerations

The following are TCP interoperability considerations:

TCP Connection Break Detection Differences

The IBM Nways Multiprotocol Access Services DLSw implementation detects that a TCP connection is broken either when a Keepalive response is not received (assuming that the Keepalive option has been enabled for the connection) or when data cannot be delivered.

TCP Connection Reestablishment Differences

Once a TCP connection is broken, the IBM Nways Multiprotocol Access Services DLSw implementation reestablishes the TCP connection when a new DLSw SSP_CANUREACH is generated upon receipt of a DLC TEST message from an end station. The IBM 6611 may not exhibit the same behavior.

Keepalive Disable/Enable Related Differences

As indicated previously, the IBM Nways Multiprotocol Access Services DLSw implementation permits the enabling and disabling of a Keepalive option when a TCP neighbor IP address is added (configured). Although TCP in the IBM 6611 DLSw implementation responds to Keepalive messages received on a TCP session, there is no mechanism to configure the resident 6611 TCP to enable the generation of TCP Keepalive messages.

Maximum Number of TCP Connections Supported

In the IBM Nways Multiprotocol Access Services DLSw implementation, there is no hard-coded restriction on the maximum number of TCP connections supported. As a result, the maximum number of TCP connections supported is directly related to a IBM 2216's available memory. In the IBM 6611 case, there is a hard-coded internal restriction of 100 TCP connections that can be supported in the DLSw implementation.

Miscellaneous Interoperability Considerations

Note the following miscellaneous interoperability considerations:

• If a problem is encountered when trying to establish a DLSw connection initiated by the IBM 6611, check the IBM 6611 configuration to ensure that MAC address filtering has not been inadvertently enabled for an associated source or destination MAC address.
• Although RFC 1434 does not specifically address the issue of orphan DLSw sessions (for example, DLSw sessions that remain in a DLSw circuit established state with no subsequent activity), both the IBM Nways Multiprotocol Access Services and IBM 6611 DLSw implementations resolve this issue by providing orphan DLSw session timeouts. DLSw sessions that remain inactive while in DLSw circuit established state for longer than 30 seconds are eliminated by both implementations.